第5章 オブジェクト技術への道
1. コンピュータ処理の中身
ソフトウェアにはプロセッサとオブジェクト、動作が働いている
プロセッサ群
コンピュータのCPUやOSのプロセス、マルチスレッドOSのスレッドのいずれか
動作群
コンピュータ処理を構成する操作群
ハードウェアレベルでは機械語の命令、ハードウェア−ソフトウェアマシンのレベルではプログラミング言語の命令
オブジェクト群
動作群を適用する対象となるデータ構造
2. 機能による分解
1. 連続性
2. トップダウン法による開発
3. 機能は1つではない
ソフトウェアシステムの変化の過程は増分的なので、元あったトップの機能は多くの機能の一つになってしまうことが多くある。
4. トップを見つける
現実のシステムにはトップが存在しない。
新たな開発は一つの具体的な機能要求を満たすという見方が疑わしい。
5. 機能と進化
トップダウン法はバッチ形式か対話形式かの選択が早すぎること、順序付けが早すぎることが挙げられる。
6. インターフェースとソフトウェア設計
7. 早すぎる順序付け
トップダウン法の弊害である早すぎる順序づけに対しては「買い物メモ(shopping list)アプローチ」が有効
1. 必要になる操作をリストアップ
2. 必要になる可能性のある操作をすべてあげる
3. 操作の順序付けの制約は最後まで遅らせる
8. 順序付けとオブジェクト指向による開発
買い物メモアプローチの基本となる概念が表明(assertion)
論理的な属性である事前条件(precondition)と事後条件(postcondition)を表し、これらを満たすことが要求される。
9. 再利用性
トップダウン法自体が再利用性の逆を意味していて、限られた仕様のモジュールが生み出される。これはプロジェクト文化的である。
再利用性のための設計はできる限り一般的な要素を作り、それを組み合わせることで解決手段を求めるためボトムアップ的である。これはプロダクト文化的である。
10. 生産と記述
トップダウン法は一度適切であると認められれば、設計を説明するのに便利だったが、何かを開発したり設計・発見する方法としては合理的ではない。
11. トップダウン設計:評価
トップダウン法でのシステム開発は短期間の便利さのために長期間に渡って柔軟性を失う。
3. オブジェクトによる分解
以下を満たすために、モジュール化の機能を明らかにするために抽象データ型の概念は適切なオブジェクトを定義できる。(次の章で解説)
1. 拡張性
2. 再利用性
3. 互換性
4. オブジェクト指向によるソフトウェア構築
オブジェクト指向によるソフトウェアの構築とは、(システムが保証しようとする機能や機能群ではなく)操作するオブジェクトの型から導かれるモジュールを基本に、すべてのソフトウェアシステムのアーキテクチャを構築するソフトウェア開発手法である。
システムが何をするかを最初に考えるな。その対象を考えよ!
5. 課題
1. オブジェクトの型を探す
2. 型とオブジェクトを記述する
3. 関係とソフトウェアの非構造化を記述する